醉袖迎风受落花——好代码的10条认知

每个软件工程师都希望看到好代码，从好代码中学习，并进一步写出好代码。然而，“横看成岭侧成峰”，每个人对好代码的理解可能不尽相同，好代码是每个人心中那个不同的哈姆雷特吗？

从不同的角度看好代码，虽然不够完善，或者有失偏颇，但可以为讨论“好代码”提供一些切入的维度。

1. 莫将画竹论难易——大道至简 

最重要的可能是——代码必须简单。对于少数人来说，复杂的代码很好思考，但是简单的代码很容易被所有人理解。如果喜欢保密的话，那么应该去从事魔术表演，而不是编程写代码的工作。

KISS 原则体现了简单就是美，据说有多个版本：

• Keep It Simple and Stupid；

• Keep It Sweet and Simple；

• Keep It Short and Simple；

• Keep it Simple, Sweetheart；

• Keep it Simple, Sherlock。

代码的设计越简单越好，任何没有必要的复杂都是需要避免的。

2. 竹竿头上愿丝多——少即是多 

一般地，更多的代码往往意味着它更复杂，往往需要更多的时间来理解，维护十行代码的成本往往不是维护一行代码成本的10倍。寻找机会，将软件分解为更少的代码模块，以鼓励代码的重用。

Less is More, 简单的东西往往带给人们的是更多的享受，好的代码也是如此。 

3. 共看明月皆如此——可读性强 

好的代码应该是所有读者都能理解的，不仅仅是为了执行而编写的。每一行都应该是出于实际的原因而写的，但是在实践中，代码会被其他人阅读，所以它必须是可读的。它应该是有意义的；命名约定、缩进、分号等都应该是提高可读性的合理语法的一部分。阅读代码，就像阅读优美的文章一样流畅。

4.云解有情花解语——自我解释

尽管注释和外部文档非常有用，但它们不是编写良好的自我解释代码的替代品。好的代码本身就是最好的说明文档，无需解释就能让别人明白，每一行代码都应该是这样。

但是，代码自解释不是不写注释的理由，即使变量、方法、类、函数、模块的名称是自解释的，但这些并不能描述出代码的全貌。

5. 清池不测通沧海——可测性好 

只要编写了代码，就可以测试代码。每次执行代码并检查其效果时，都在测试它，但这不应该是测试代码的唯一方法。单元测试是好代码的一部分，单元测试常常记录了代码的意图。单元测试用例能成功运行的前提是该方法内部的所有逻辑必须是能正常运行的，编写可测试的代码使其具有了可塑性。

6.伐竹为桥结构同——可被重构 

重构是在不改变行为的情况下改变实现。如果没有测试来证明行为没有改变，就不能真正重构。如果有一个公共接口，那么对代码进行更改，以使公共接口更改，这不是重构，而是重写。

真正可以重构的代码是可以用更少的努力改进的代码，不费吹灰之力就能改进的代码是好代码，价值体现主要在于可维护性和可扩展性。

7. 因君为问平安否——安全可靠 

采用良好的编程风格，可以防范大多数编码错误。用怀疑的眼光审视所有的输入和所有的结果，采用防御式编程，直到可以能证明它们正确时为止。如果无法使用安全的数据结构，就要对不安全的数据类型系统地使用安全操作。重视所有稀有的资源，审慎地管理它们的获取和释放。

安全可靠是永恒的主题，可靠、可预测和平实的代码才可能是安全的，重视安全从每一行代码做起。

8. 专一始终无变异——职责单一 

好的代码“块”有一个单一的责任，应该做一件事，并做好它，具有功能的明确性。符合单一职责原则的代码会由更多的小规模但目标更明确的代码组成，然后通过接口抽象以及在运行时将无关功能的责任委托给相应的接口来达成目标，目的就是提高代码的可维护性、可读性、扩展性。

9. 有似山开万里云——公开分享

编程就是一项运动，通过不断地练习，不断地向他人学习，才能不断地提高代码的质量。改进代码的好方法之一是共享代码并通过共享接受更改，也是另一种程度上的复用。代码开源或许是走向好代码的路径之一，可惜老码农从社区获得很多，贡献很少，惭愧之至。

10.万态千端一瞬中——只有更好

总有更好的程序员写出更好的代码，总会有更好的解决方案，可以通过共享和重构来改进代码。如果好代码可以改进，就应该改进，因此是暂时的。好代码可能不是一次性的，要为未来写代码，没有最好，只有更好。

关联阅读：